	    ________					 27-January-98
	   /	    \	      ___________
	  .\_	 _   \......./		 \.............
	  : /	/ \   \      \_____    __/[J3d!]      :
	  :/   /  /   /		   \   \ /\	      :
	  /   /  /   //\	   /   //      \   /\
	/       //	 _   \ ___/   //   /\	\ /   ____   \
	\__________//	//   //	     //	  /  \	 \\   \	 /   /
	  :	    \	\\  / \_____/ \	  \	  \\   \/   /
	  :	     \	 \	       \______/\__/ \	\__/
	  :...........\______/.......................\	 \
	    [s N E S  r O M  t R A N S L A T I O N S] \__/

		      Search Relative v2.10
		      =====================


Introductory Information
------------------------

   Every computer ever made has had some method of displaying and encoding
text. A computer doesn't recognize the letter 'A' in its microprocessor;
everything within the computer is dealt with using hexadecimal bytes like
00, F1, and AC. In order for the computer to be able to translate these
hexadecimal numbers into letters and numbers that you and I read, a conversion
table is used.There will usually be 255 possible entries within a table
since bytes only go up to FF (255 in decimal numbers). But, usually only
about 1/2 of them are used, since alphabets hardly take up 255 slots.
For IBM compatible computers, the table standard has been known as 'ASCII'. 

   Within the ASCII table, hexadecimal number $41 (hexadecimal numbers are
usually denoted with a $ in front of them) represents the letter 'A'. From
then on, $42 stands for 'B', $43 for 'C', etc... up to 'Z'. The lower case
letters start at $61 ($61 for 'a'). Also, the characters '0..9' are represented
by $30 to $39. The other bytes consist of less common characters such as the 1/2
symbol (), the copyright symbol (), and the asterisk (*). Also, some of them
are used for control codes like $07, which is reserved for the system beep you
hear when you turn on your computer. 

Not all computers use the ASCII standard. The Macintosh does not use the ASCII
standard, and neither do gaming consoles. this is where consoles are such a
pain in the ass - almost none of them use the ASCII standard for their lettering
and to make it worse, there is no standard amongst console systems. I could be
editing CastleVania today and Final Fantasy tomorrow and I'd have to find out
separate tables for both of them.


What does it do?
----------------

   If you had to visualize what SearchR does, imagine it like this: the table
is the top most row with the numbers on it. let's pretend it stetches all the
way from $00 to $FF. What SearchR will do is take your string and match it to
all 255 possible combinations of alphabets. in a sense, it'll slide the alphabet 
along the entire 255 possibilities and report the matches.

[00 01 02 03 04 05 06 07 08 09 0A 0B .. F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF]
[A B C .. X Y Z] 
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z] 
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]
 [A B C .. X Y Z]

What SearchR does is it will take a word you give it that you know is going to
appear somewhere in your file or ROM, and search all 255 possible combinations
of that word until it finds some matches. It searches by assuming that if the 
letter A is for example entry $00, then B must be entry $01, and so on. it does 
this all relatively with variables; first it assumes letter a is $00 and 
searches the file for your word using that table index, reports the matches, 
and then moves on to assume letter A is entry 01 and letter B is entry 02. 
SearchR will do this repeatedly all the way up until letter A is all the way up 
at the end of the table index. so simply put, you have searched the file using 
all possible table combinations. 

Sample SearchR output:

  File: xmen.smc (Spiderman and the X-men)
String: FOLLIN

019E9C: 10 19 16 16 13 18 00 00 [........] a=?? A=0B 1=?? [FOLLIN..]
019FF0: 10 19 16 16 13 18 FE 00 [........] a=?? A=0B 1=?? [FOLLIN..]
019FFE: 10 19 16 16 13 18 FE FF [........] a=?? A=0B 1=?? [FOLLIN..]

  File: mana1.smc (Secret of Mana)
String: Mana Sword

0908A3: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo]
092EB0: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo]
092EDE: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo]
093391: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo]
<etc...>

   The way you'll know if you've hit a correct table is if you see a matched
word you were looking for, and it's followed by another word you knew you'd
see right after it. For example, in the game Secret of Mana for SNES, the word 
'Mana' is often followed by the word 'Sword', since it's a key item in the 
game. sure, you might see 'Mana' here and there if it happened to turn up 
somewhere in the code by coincidence, but when you see 'Mana' followed by 
'Sword', the chances of coincidence get increasingly smaller. thus, you know 
you've found your font out of narrowing down the evidence.

   This is the extent of SearchR's function. once you've gotten your table,
it's up to you to edit your rom based upon the table you now have. many rom
editors have popped up in the past months, nakely X-Late and ROMedit. or,
if you prefer straight editing, use a hexeditor.

*NOTE* be careful of your capitalization, since as you can see here we searched 
for 'Mana'; not 'mana', and definitely not 'MaNa'. Each of these searches would 
have brought up different results.


What does SearchR's output mean?
--------------------------------

Column1 Column2 Column3 Column4 Column5
0963C0: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo]
096446: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo]
0967B3: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo]
0994BA: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo]

- Column 1: The location of the matched phrase in the file, in hexadecimal 
offset numbering.

- Column 2: These are the hex bytes as they appear in the file itself.

- Column 3: This is what Column 2's bytes look like through the ASCII 
standardized table. in other words, it's what you'd see if you looked at it 
through a normal hexeditor's text window.

- Column 4: This tells you where the ROM's table begins. here, A=9B, so B=9C, 
C=9D, etc.

- Column 5: This is the text as it appears through searchR's table parser. you 
can see the following text as well as the text you entered, so you'll have a 
little better idea if you know if that particular string is the one you're
looking for or not.

*NOTE* all period marks are used to signify any byte that's not part of the 
normal alphabet. For instance, the space bar doesn't produce any letter or 
number, therefore it's denoted by a period.


Other nice little things
------------------------

   There's a wildcard option in searchR, used with the "?" key. for those of
you who don't know what a wildcard is, read on. let's say you wanted to look
up a word but you weren't sure of a letter in the middle of it, for example,
a_nS (with _ representing some letter you couldn't recognize). By entering
your string as a?nS, you bypass that letter altogether and tell searchR just
to search for the three surrounding characters. then, once you've found what
you're looking for, you can see what that character really is.

   There are many, many other uses for the wildcard. you can check whether a
word was capitalized or not, or you can wildcard an entire word to check
surrounding words for cross-checking.


The Hex View Option
-------------------

   Ok, this is a very quick example to show you what the new hex view feature
is used for (text by [J3d!]):

1) Select the file to search. Probably some console game.
   (Click on the 'Change File' icon or press 'f', use the
   file selector that appears).
2) Enter the text to search for (move the cursor over
   the black area next to 'SearchText:', use the keyboard
   to edit the textbox).
3) Click on 'SearchR' or press 'r' to search the file.
4) Check the results that appear in the list (if none appear,
   try a different search string).
5) Highlight one of the results using the left mouse button.
6) Click on Hex View (or press 'h'). You will now see the
   file displayed as both hex bytes and relative text characters
   (ie. the same format as most hex editors, but with relative
   text instead of plain ASCII).
7) While in this view, you can scroll around the file using the
   scroll bar and the keyboard. The following keyboard buttons
   are available:

   Up Arrow  - Up 1 line         Down Arrow - Down 1 line
   Page up   - Up 25 lines       Page Down  - Down 25 lines
   Ctrl+Home - Top of file       Ctrl+End   - End of file

   The view jumps to the location of whatever result you had
   selected and uses the relative font table found by that
   result (I guess the next step is to add a full font table
   editor or something?).
8) When you are bored, click on Back (or press 'b'). You will return
   to the list of results and the main menu.

For Japanese ROMS (RPG), replace the font(s) so that the name select
screen appears with English chars (ie. A..Z and/or a..z). Start a
new game and name your character. Save the game as soon as you can,
then search the saveram (.srm) file for the character's chosen name.
(As .srm files are max. 32k, this method works well)

  File: dragon3e.srm (Dragon Quest 3 Remix translation, saveram file)
String: Jedi

000EE8: 15 29 28 2D AC 00 00 00 [.)(-....] a=25 A=0C 1=?? [Jedi....]


The Gfx Viewer
--------------

   The gfx viewer is designed to support many of the common gfx
formats used in console/arcade roms. I added it as I did not have
anything to view Genesis gfx with. It supports other formats as well
now, although it's better for some formats than others...
   You can use Up and Down to move up/down a row of gfx tiles, Page Up
and Page Down to move up/down a screen of tiles and Left and Right to
move up/down by Just one byte.
   Use the mode button to select the different gfx modes. The n-plane
modes use n-bits from n-bytes to determine the pixel colour. The n-bpp
modes use n consecutive bits to determine the pixel colour, the next
n-bits for the next pixel etc...
   For each mode, you can choose to view 8x8, 8x16, 16x8 or 16x16 sized
tiles. You can also switch between 'snes mode' and 'normal mode'. This is
just a hack for the snes modes...

Below are the best modes to use for various types of rom:

GameBoy:

 - 2 colour (1plane)
 - 4 colour (2planes)

GameGear:

 - 16 colour (4planes)

Genesis:

 - 16 colour (4bpp)

MasterSystem:

 - 16 colour (4planes)

MSX:

 - 2 colour (1bpp)
 - 16 colour (4bpp)
 * MSX uses disk images, most gfx appear messed up.

NeoGeo:

 - 16 colour (4bpp)
 * Only tested with Puzzle Bobble roms.

NES:

 - 2 colour (1plane)
 * Not very well supported.

Super NES:
 
 - 2 colour (1plane), Snes mode.
 - 4 colour (2planes), Snes mode.
 - 16 colour (4planes), Snes mode.
 * Not as good as NaGA.


Many arcade roms can be viewed too...
Oh, 8bpp mode is implemented, but 8plane mode is not...
If you want to view/edit snes gfx, you are better off getting NaGA,
as it supports all common snes modes and allows you to edit the
tiles... Oh, NaGA is disturbingly fast too :).


Credits
-------

Richard Bush/[J3d!] (rbush@firenet.net) - SearchR coding
Demi (demi@frognet.net)                 - Improved Documentation

* Demi has very kindly rewritten most of the documentation above,
  it should make things a lot clearer for most people :). If you
  see a bit you don't understand, I ([J3d!]) probably added it...

* The interface uses a 640x480 8bpp screen mode, Allegro is supposed
  to autodetect the best mode to use (VESA1/VESA2 etc..), and it works
  for many people. If it does not, get Scitech Display Doctor and you
  should be fine. If you still can't get it to work, sorry, but I don't
  know why. I can only test it under Win95 dosbox and the version of
  dos that comes with Win95 :(.


What's New
----------

v2.10

- Detects and DeInterleaves .SMD format Genesis ROMs.
- Gfx Viewer supporting 1,2,4 and 8 bitplanes in chunky
  and planar formats, plus tile sizes of 8x8, 8x16, 16x8
  and 16x16.

v2.08

- View the whole file using the search results.
- Last file/search string saved to a settings file
  (SearchR2.ini).
- SearchR routine warns if the search string is too
  general (eg. 3 or more searchable characters).
- Compiled using Allegro v3.0 instead of v2.2.

v2.01 (unreleased)

- Documentation completely overhauled by Demi.

v2.00

- Added a primitive GUI, using the Allegro Library
- SearchR algorithm now makes use for the following
 characters: 'A'..'Z', 'a'..'z' and '1'..'9'. Also,
 you can mix them in the search strings now.
- More detailed search results.

v0.01

- First Release
- Only good for lower or upper case search, not
 both together...

* Do not spread this about without permission, if you
* did not get it from the address below, tell me!

 _/\__
 / \/_
,-----------[Richard Bush [J3d!] ]--------O---(O O \/_----.
| o (___/ \/_ |
| ICQ: 2365132 Email: rbush@firenet.net (^^'\_/ \/_ |
| <__________> |
| WWW: http://www.geocities.com/TimesSquare/Castle/6195/ |
`----------------------------------------------------------'